Hi,

my empeg shows an annoying effect - I think it does this since I installed the PCATS tuner quite some time ago, but I am not 100% sure (the tuner works great, including stalk input).
It only happens in the car, not at home in AC mode.

What happens is that during playback, it behaves like some keys were pressed. This is usually either "next track", or the combination "next track + pause", or just "pause". Also, the "play" icon pops up in the lower left corner from time to time, which may indicate "play" is also affected.

Sometimes, I can drive for long periods without problems, sometimes it happens twice during a 20-minute drive.

I tried disabling stalk input to no avail (and verified it is really disabled), and I also tried inserting popup messages at different points in the hijack code where input events are handled - I got lots of output from IR/button/stalk events, but the phantom keys bypassed them all.

I am looking for any idea how to track this down.

cu
Michael

This is going to sound a little odd, but I had something similar due to my second hard disk not working correctly. The player would load the playlist correctly, but would then fail to load the track from the second disk. It would then skip tracks. I think that if the player skips too many tracks, it pauses playback. It usually happened at a track transition, rather than in the middle of the track, but you never know...

In my case, it was either a loose IDE cable, or a power problem (I reseated the cable, and I had the car battery replaced at a service a few days later).

This might not be your problem, but you're going to take forever trying to track down phantom button presses (although Hijack has some nifty stuff that can help you), so rule out HD and power supply problems first. The fact that it works fine on AC suggests to me that it might be a power supply problem.

The blinking play symbol is something that a couple of other people, including me, have seen. It appears every 30 seconds if I remember rightly.

I don't have the other issues you talk about though. I know that the blinking play symbol that I see can't be caused by the tuner, because it happens out of the car as well.

Hm,,

I don't think that is the cause. First, the skip/pause happens at random times - it will play the same track fine when I press back. Second, Hijack should display disk errors - I had those in the beginning before I fixed the IDE cable.

Now that you mention the harddisk - I completely forgot to tell that the problem occurs on two units: I used a friend's empeg for some time in my car, to test that the button kit installation that I did for him worked fine. I then swapped the harddisk back into my player. Both units show the same behaviour, so the problem must be either in the car/tuner/power supply external to the player, or the disk.

cu
Michael

Is it possible your units have the fascia over tightened and the vibration in the car is causing multiple simultaneous button presses? Just a thought. You might try loosening the fascia screws or even riding around without lens, button caps and fascia to see if the problem goes away.

Hope this helps,
Stu

Hi,

I am quite sure it is not caused by the front buttons being pressed. During my experiments, I had debug messages attached to the buttons in hijack, which triggered when pressing the buttons, but not during the phantom events.

cu
Michael

You mentioned it may have happened since the tuner was installed. The fact it happens on two unrelated empegs means it's more than likely an issue with the install.

Is it possible the tuner is creating stalk events? You say you had debug messages attached to the buttons. The stalk events are different to the button events (IIRC) although they may do the same thing like skip a track.

You could just temporarily unplug the tuner. If it happens just once without the tuner, you can at least rule it out then.

Isn't there a hijack command to disable the stalk?

I think so, although it may be slightly broken - I had some issues with completely disabling stalk, so I added my own code to hijack, together with a menu to enable/disable stalk on the fly - this worked insofar as my stalk was disabled when it was supposed to, but the phantom events still showed up :-(

cu
Michael

There is a FAQ entry about the IR sensor and missed interrupts. See if that applies?

It most certainly is not broken.

If you use it and still get phantom events, then you can be 100% certain that they are not coming from the stalk wiring.

-ml

Not when at home - I will see if I can check while in the car, the problem is I have no easy access to the serial port there.

cu
Michael

I have to re-check this, since the first attempts were some time ago, but when I tried, the stalk still worked, even when it was supposed to be disabled.

cu
Michael

The correct steps to do the stalk thing are in the same FAQ entry about the missed interrupts, here. Try the stalk entry in config.ini and see if the problem goes away.

Thanks. At least at home, the missed interrupts look sane (less then 20, not increasing over 30 minutes).

I managed to disconnect the tuner without pulling out the cage - I will watch if the problem is gone and report back.

cu
Michael

Hm - not sure who is the culprit, but further testing shows that
[hijack]
stalk_enabled=0

does not work (ie. the stalk is still active) unless I put a ";" on the end of the line. Without the comment, hijack complains about an unparseable line (which I only noticed today, with a serial console attached).

cu
Michael

Okay, here is the current status of my investigations:
- With the tuner disconnected, absolutely no phantom keypresses have turned up. This should also mean that the IR receiver is not the culprit (unless the tuner somehow influences the IR receiver and only when in the car).

Today, I re-attached the tuner and disabled the stalk input using the hijack config entry. I verified that the stalk is really dead now. During a one hour drive, I had 3 phantom events again.

This means that somehow the tuner is causing this, but not via the stalk input channel. Any good ideas what might be going on here?

cu
Michael

So you're saying it needs to read:
[hijack]
stalk_enabled=0;

?

I've edited the corresponding FAQ entry to read that way.

Strange. Mark put that feature into hijack specifically at my request, and it's works just fine, for me, without the ";".

I'm curious... are you editing the config file in Windows? Maybe there's a ^M at the end of the line, or something, which the ";" masks.

No. I used joe and ncftp in Linux. I can do more detailed checks when I am back at home next week.

Exactly that. A single trailing semicolon is enough. Without the semicolon, I get errors on *all* commands in the [hijack] section:
[hijack] ERROR: "stalk_debug=1"
[hijack] ERROR: "stalk_enabled=1"
[hijack] ERROR: "volume_boost_FM=4"
[hijack] ERROR: "volume_boost_AM=4"
[hijack] ERROR: "volume_boost_AUX=0"

This is hijack v485, but the changelog does not indicate any fixes in that area in newer versions - I stay at v485 currently in order not to change behaviour while tracing down the original problem ...

Wow, that's odd. Really sounds like extra bytes being added to the end of each line.

Hi,

I managed to install a serial cable in the car so I could connect an old notebook to the empeg, do do some printk debugging.

I added printk's in the read function in multiple drivers:
- empeg_input
- empeg_rds
- empeg_state
- empeg_usb
plus in hijack.c (hijack_enq_button, hijack_handle_button).
This works fine - I get debug output from IR events, button presses, stalk ... plus regular 8-byte reads from the RDS device.

Now the strange thing is: when the empeg switches to the next track or pauses during playback, nothing shows up (except the regular rds reads, which continue as usual).

So it seems I am still missing some channel via which the player gets these annoying events - where should I look?

That's quite interesting!

Another place I can think that the empeg would interpret commands would be from the serial port. Serial commands can make it switch tracks.

I can also imagine that it might pause during playback or switch tracks if it hits a corrupted MP3 file.

Yeah, exactly. The idea of *requiring* a trailing semi-colon on each line is absolutely bogus.

Cheers

How are you editing the config file? Windows editor and its converting it to DOS line endings?

He stated earlier in the thread what editor he was using. Non-windows, IIRC. I'm not familiar with the editor so I don't know whether it would be a factor or not.

Linux and joe. Joe has a "-crlf" option, so I'd imagine that it can autodetect if a file already has it, and "do the right thing" transparently [and it does].

I'd suggest running dos2unix on the config file before putting it back on the player, and see if that resolves the problem.

I am quite sure that's not the case. Not sure if this gets through unwrapped, this is the beginning of the config.ini:
0: 5B 68 69 6A 61 63 6B 5D 0A 73 74 61 6C 6B 5F 65 [hijack].stalk_e
10: 6E 61 62 6C 65 64 3D 30 0A 73 74 61 6C 6B 5F 64 nabled=0.stalk_d
20: 65 62 75 67 3D 31 3B 0A 74 72 61 63 65 5F 74 75 ebug=1;.trace_tu

Hijack complains about "stalk_enabled=0", but not about "stalk_debug=1;". I edit that file locally and send it to the empeg using ncftp (yes, I tried "binary", although that is the default).

hm. guess i should try taking the fascia off. started getting phantom pause/unpause when i hit bumps!

It should not be complaining about that.